UML is a visualisation method that allows you to keep a broad overview of your software system. Because it is relatively popular, research has already started on how to do software metrics on these visualisations \textbf{\cite{MetricView}}.

In this chapter I will discuss some metrics that can be calculated over UML visualisations and I will show how these metrics might show why a system in maintainable or not.

Because we are looking at a visual representation most of the SIG metrics can not be used by us, therefor we discuss the following four metrics on the structure of UML:

\begin{enumerate}
  \item Cyclometic Complexity
  \item Object without a type or name
  \item Coupling
  \item Cohesion
\end{enumerate}



\subsection{Cyclometic Complexity}

Cyclometic Complexity is exactly the same metric as we have seen in the SIG model. Most diagrams in the UML language do not support \textbf{if else} statements and loop but there is a type of diagram that allows you to make decisions in UML. The Sequence Diagram allows you to do this.

As practice has shown us, Cyclometic Complexity is quite a good indicator of maintainability, though others might say otherwise.

The only problem with this technique is that most systems are not fully modelled in UML. Often the architect of a system only does this to show the developer that at this point an important decision should be made. But all \textbf{if else} statements that check whether the data is actually correct are lost in the model. These are only programmed during the development fase. This means that when you try to understand the sytem by looking at the architecture you only see the important discisions.

Thus if you understand the architecture you are less likely to introduce a faulty statement in the code, because you know why certain descisions where made. Though searching for errors might be more difficult because you might get lost in all the statements that introduce complexity which you can't find in the architecture.



\subsection{Objects without a type or name}
Because UML is not something that is compiled into an application and because there is nothing that checked whether the system is complete, it can happen that you have objects in your visualisation that have no type or name. This can happen when the architect need an object that has certain functionality when he is working on a Sequence diagram and he forgets to specify in a class diagram what that object should look like. This means that when a two developers find these objects in different diagrams they might both implement it in a different way at a different spot, meaning your get "dupilcate code". 

As we have seen in the SIG model Duplication is a measure which decreases maintainability.

The same can happen when an architect forgets to name an object. This means that developers do not know who might already have implemented it. Resulting in duplicate implementations or more objects than actually needed, or problems with the fact that someone finds out and merges the two objects, which no one knows about. 

Both objects without a type and objects without a name can cause problems during development which leads to lower maintainability.



\subsection{Cohesion}
With Cohesion we measure how strongly related code within a software system is \textbf{\cite{Harpal199565}}. We want high Cohesion because that makes sure that as many objects as possible use that code. Meaning you avoid code duplication. Avoiding code duplication also decreases complexity in the entire application.

In the end this means that high Cohesion makes sure that maintainability is increased.

In a UML diagram you can easily calculate Cohesion. Sequence diagrams show how methods call each other, from this you can easily calculate the Cohesion for all objects. 

The disadvantage ofcourse is that if your architecture only consists of class diagrams and misses the sequence diagrams all together you won't be able to calculate Cohesion.



\subsection{Coupling}
Coupling is the dependency between different objects of a software system \textbf{\cite{Harpal199565}}. Coupling has a strong relation with Cohesion. Low Coupling often means high Cohesion and the reverse is also true.
Highly coupled systems are often called tightly coupled systems. Tight Coupling means that modules are more independent.

Tight Coupling is not something you want because changes to you systems often have a ripple effect that forces you to review all your code, because many parts of the system are actually the same and have to be edited if you change that code somewhere else in the application.












